Power CD-ROM!! 8

home *** CD-ROM | disk | FTP | other *** search

/ Power CD-ROM!! 8 / Power CD-ROM 8.iso / docs / os2vswin.txt < prev next >

Wrap

Text File | 1994-10-20 | 31.5 KB | 706 lines

OS/2 Warp Vs. Windows 95: A Decision Maker's Guide to 32-bit Operating System Technology IBM Personal Software Marketing October 1994 EXECUTIVE SUMMARY ================= This document is designed to provide the corporate decision maker with benefits of OS/2 and important information about weaknesses in Microsoft's forthcoming Windows 95 operating system. At the heart of the discussion are key architectural, operational, and strategic flaws in the current Windows 95 OS design and strategy - flaws that Microsoft has either downplayed or ignored in its efforts to market Windows 95 as the "next generation" Windows desktop platform. For example, you'll learn: Why OS/2's ability to isolate individual 16-bit Windows applications into their own separate VDMs provides a level of (OS2CHG.TEX 3%), (H)elp (F)ind (E)nd (P)gUp (T)op (>), More? ns inter-application protection that is unavailable under Windows 3.1 or Windows 95. How this same isolation also allows OS/2 to preemptively multitask existing 16-bit Windows applications, with no impact on native application performance. Why having a comprehensive System Object Model (SOM) is important, and how OS/2's SOM implementation acts as the "glue" to the WorkPlace Shell interface. Ways in which OS/2's Virtual DOS Machine implementation is more flexible than Windows 95's. Major topics include: Architectural flaws that may compromise Windows 95's stability when running 16-bit Windows applications. How these same flaws also limit Windows 95's current multitasking capabilities with a mixture of application types. Why the lack of a System Object Model makes the Windows 95 interface "fragile." Ways in which Windows 95's DOS heritage render the product inflexible when dealing with 16-bit DOS device drivers. At the end of each section, a direct comparison is made between the Windows 95 implementation of a particular subsystem or feature/function, and that of the leader in 32-bit desktop operating systems, IBM's Operating System/2. The material in this document is based on an in-depth analysis of the following non-confidential currently available sources : Microsoft's public statements regarding Windows 95's design characteristics, various presentations given at trade shows by industry consultants, and the References referred to at the end of the document. OS/2 - THE RIGHT SOLUTION Choosing the right operating system. In many ways it's the most important personal computer technology decision you'll make in this century. Choose wisely and you'll reap the benefits for years. Choose poorly and you may find yourself in a quagmire of under-performing software and inadequate computing power. So just what constitutes a wise choice in today's confusing PC marketplace? Simple: the product that does the best job of preserving your existing investments while opening the door to the future. In a nutshell, the wise choice is Operating System/2. OS/2 - THE WORLD'S MOST POPULAR 32-BIT OPERATING SYSTEM FOR IBM AND IBM COMPATIBLE PC's Why OS/2? Because it represents the most logical upgrade path for today's PC users. OS/2 preserves your investment in 16-bit DOS and Windows applications while providing access to a new world of 32-bit, object-oriented technology. Upgrading to OS/2 is a win-win proposition. Just ask any of the more than five-million OS/2 users - over 8 times as many users as Microsoft's current 32-bit offering, Windows NT. These are people just like you who have outgrown their existing DOS or Windows environments and who are looking for more - more power, more functionality, more stability. With OS/2 they've found a powerful mix of backward-compatibility, 32-bit processing power, and ease of use, along with the kind of rock-solid reliability that only a mature, established operating system platform can deliver. With the release of V3, OS/2 is entering in its 3rd generation, and the product's reputation for reliability and price/performance is unmatched in the PC industry. BUT WHAT ABOUT Windows 95? This is the question that perplexes both corporate decision makers and end users alike. With all of the media hype surrounding this "next generation" of Microsoft Windows, many customers feel paralyzed when making operating system purchasing decisions. The fear of "missing-out" on Windows 95 is overwhelming for some. But as experience with the initial beta release of Windows 95 has demonstrated, Microsoft's "next generation" of Windows is far less compelling than they would lead you to believe. In fact, the core of Windows 4.0 is probably running on a PC near you: it's called Microsoft Windows 3.1. ARCHITECTURE ============ Windows 95 - SAME CODE, DIFFERENT PACKAGING "How can that be? It looks so different!" Looks can be deceiving. While Windows 95 indeed sports a radically different user interface (more on that later), as you peel-away the layers of GUI and packaging you'll discover a product that looks remarkably like Windows 3.1. In fact, Windows 95 retains so much of its original DOS/Windows heritage that it retains the latter's most notorious operational characteristic flaw: instability. For example, under Windows 3.1 all applications, as well as the operating system code itself, share a single memory address space. While such a memory management model breeds performance, it also means that an error in any single application can potentially crash the entire operating system. This crashing phenomena is often referred to as a General Protection Fault or "GPF," and has been the bane of Windows users since version 3.0. It is because of this inherent architectural weakness that Windows 3.1 has gained a well known reputation of being an unstable, unreliable operating environment. Under Windows 95, this same single address space model (referred to as the "System Virtual Machine") is retained, along with the inherent weakness of leaving key portions of the operating system code exposed to potentially buggy applications. Thus the same application failures that crashed Windows 3.1 can potentially bring down the entire Windows 95 operating system. To their credit Microsoft has made great strides in "cleaning-up" many of the bugs in the original Windows 3.1 code while preparing it for inclusion with Windows 95. However they cannot avoid the inherent architectural flaws that the Windows 3.1 single System VM model introduces. There will always remain the possibility of an errant application causing a disastrous system crash. OS/2 - SAME CODE, BETTER IMPLEMENTATION OS/2 eliminates the Single System VM stability problem by letting you run Windows applications in their own separate sessions, or "VDMs" (Virtual DOS Machines). Thus if an application fails under OS/2, the effect of the failure is limited to the individual session. Other applications, as well as the operating system itself, remain unaffected. And by retaining much of the original Windows 3.1 code base, OS/2's environment remains highly backward compatible with Windows 3.1 applications and device drivers. MULTITASKING ============ Windows 95 - A "SEMI-PREEMPTIVE" TASK SWITCHER? One of Microsoft's biggest selling points for Windows 95 has been the promise of a new breed of 32-bit Windows applications. These applications are to be preemptively multitasked by the Windows 95 operating system, and will have access to advanced performance enhancing techniques like multi- threading. Let's define the difference between preemptive and cooperative multitasking. Preemption is an involuntary loss of control which the application must handle. Cooperative multitasking is where the application is given control and it is the application's responsibility to give up control so that other applications may execute. The move to a preemptive multitasking model represents a significant departure from Windows 3.1. Under that environment applications must "cooperate" in order for multitasking to occur. Each program "yields" to the operating system so that it can switch control of the PC's CPU to a different application (this is often referred to as "cooperative multitasking" or "task-switching"). It is a well know fact that the Windows "cooperative multitasking" model is inefficient. It also forces programmers to code their applications in a way that adds complexity and hinders performance. So it comes as no surprise that Microsoft's promise of preemptive multitasking in Windows 95 has been heralded as one of the new platform's most important features. But the truth is that Microsoft isn't telling the whole story when it comes to Windows 95's multitasking architecture. In reality, unless you work exclusively with 32-bit "Win32" applications, you won't reap the benefits of true preemptive multitasking. Why? Because of Windows 95's heavy reliance on 16-bit, Windows 3.1-era code. Under Windows 95, both 16-bit and 32-bit applications rely on 16-bit code structures that reside within the System VM - code that has been brought over from Windows 3.1. While the "bitness" of the code itself isn't significant, the environment from which it hails is. Windows 3.1 was written as a cooperative, not preemptive, multitasking environment. When you introduce portions of its code into a preemptive setting, where more than one task may be vying for its services at any given time, the code could break. To safeguard against this sort of "code breakdown," Microsoft has serialized access to key portions of the Windows 95 infrastructure - most notably the USER (window management) and GDI (graphics device interface) subsystems. In technical terms, this is referred to as a "non-reentrant" design, meaning that only one application may execute within these modules at any given time. While such an approach works with Win32 applications - which can be preempted at any point during their execution - it breaks down once a 16-bit Windows (Win16) application begins to execute. As it stands, currently shipping Win16 applications cannot be reliably preempted during execution. Attempting to do so while such an application is calling on a non-reentrant, 16-bit code module can cause the entire operating system to crash. To avoid this latter scenario, and thus retain some semblance of multitasking, Microsoft has implemented a special locking mechanism. Dubbed "WinMUTEX," this mechanism denies access to the older code when a 16-bit application has called on its services. Thus only the currently running Win16 application has access to the 16-bit code - all other applications, including Win32 applications, are "blocked" from executing until the 16-bit application has finished and the environment has been made safe for the next task. In practice, the performance hit associated with this locking phenomena is minimal when running 32-bit applications exclusively. However, when you introduce a mixture of 16 and 32-bit applications - the most likely scenario given the projected lack of available Win32 products - WinMUTEX becomes a major problem. Most 16-bit Windows applications are notorious for failing to yield properly under Windows 3.1, and until they do so under Windows 95, all other applications will be blocked from accessing USER and/or GDI (in reality, only 50% of GDI calls are affected - but these are the most common functions so the net result is the same). Taken as a whole, these two compromises - the serialization of subsystem access and WinMUTEX - create what would best be described as a "semi-preemptive" multitasking environment. And while the resulting "hourglass" is expected under a cooperatively multitasked environment, it seems out of place in a "next generation" Windows that supposedly "preemptively multitasks" native Win32 applications. OS/2 - TRUE PREEMPTION FOR BETTER PERFORMANCE OS/2 has featured true preemptive multitasking of native applications since day one. Regardless of the mixture of application types, OS/2 can continue to smoothly multitask dozens of concurrent programs, and its reentrant subsystems allow it to service multiple concurrent requests without the overhead of a "WinMUTEX" implementation. And thanks to its ability to run them in separate VDMs, OS/2 can also preemptively multitask existing 16-bit Windows applications which Windows 95 can not. Thus you can have DOS, Windows, and OS/2 applications running concurrently, side-by-side, without any performance penalties and all preemptively multitasked. This is a feature that Windows 95 seems to be unable to match without underlying architecture changes, and a welcome addition to any power-user's arsenal. INTERFACE ========= Windows 95 - BEAUTY THAT'S ONLY SKIN-DEEP Another major feature of Windows 95, and one that has drawn considerable attention from the industry press, is its new user interface. Terms like "object-oriented" and "desktop metaphor" are often used to describe this radically different Windows look. But as with most of Windows 95's underpinnings, the actual foundation underneath the product's user interface is nothing more than an extension to what already existed in Windows 3.1. Unlike a true object-oriented environment - where links between individual objects are "live" and updated automatically - the Windows 95 GUI is static. "Objects" on the Windows95 desktop are merely pointers to files on the disk. "Properties" for these objects are stored in .INI files (for Windows applications) or .PIF files (for DOS applications), and links between them (called "shortcuts" under Windows 95) are equally static. For example, if you create a shortcut to an executable file and place it on the Windows 95 desktop, then rename the original executable, the shortcut will essentially be severed. To re-establish it you'll have to re-create the shortcut from scratch. In a true object-oriented environment, all shortcut-like links to the executable would have been updated automatically by the underlying object management model. Windows 95 has no such underpinnings, so links are easily broken by novice users who are unfamiliar with the crudeness of the Windows 95 interface. Going hand-in-hand with Windows 95's shortcut mechanism is the product's support for long file and directory names on FAT volumes. Microsoft is emphasizing Windows 95's ability to automatically convert long file/directory names into 8.3 character abbreviations for compatibility with existing DOS and Windows applications. What they seem to be ignoring, however, is the fact that promoting the use of long names can be disastrous when there is no underlying object model. Take, for example, the novice user who, upon discovering long filenames, decides to "reorganize" their hard disk. They gleefully rename directories at will, unaware that they are severing shortcut after shortcut in the process. Suddenly none of their applications work, and I/S is called in to undo the damage (which in some cases may mean reinstalling both operating system and applications). The Windows 95 desktop itself is not an OLE 2.0 object. This statement in itself has no ramifications until you start understanding what type of integration is lost due to this lack of object technology. This deficiency in the product, means that an application is not well integrated with the desktop and does not inherit any of the advantages like Drag 'n' Drop support. Heralded by Microsoft as one of Windows 95's key selling points, the new Windows interface may in the end prove to be one of its biggest flaws. Without an underlying system object model to tie everything together, this new "shell" may prove to be an I/S support nightmare. OS/2 - TRUE OBJECT-ORIENTATION OS/2's WorkPlace Shell is a true object-oriented interface. The underlying System Object Model (SOM) provides complete object-tracking so simple operations like dragging a directory to another directory won't invalidate links and other interface structures. Thus it's easier on both novices and IS support staff alike. SOM also allows applications to fully manipulate the WorkPlace Shell interface. A good example is cc:Mail for OS/2, which uses SOM to seamlessly integrate its in/outbox interfaces with the WorkPlace Shell desktop. This level of integration isn't possible under Windows 95 since its shell is itself not an object. APPLICATION SUPPORT =================== Windows 95 - STILL DOS AFTER ALL THESE YEARS "Windows 95 eliminates the need for DOS. It is a true operating system..." This is one of the more colorful myths surrounding Microsoft's Windows 95 operating environment. Microsoft claims that Windows95 eliminates the need for DOS - that DOS and Windows are now completely integrated and that all the old restrictions that DOS brought to the table have been eliminated. While it is true that you will no longer have to purchase a separate DOS product in order to install and use Windows 95, this in no way constitutes the eradication of DOS as a part of the Windows operating system equation. DOS is still there, lurking in the shadows. It's just been cleverly disguised by a different Windows GUI. And though much of its functionality - including file system access - has been replaced by 32-bit Windows 95 VxDs (Virtual Device Drivers), there are still ways in which DOS can hinder the Windows environment. Take real-mode device drivers, for example. Under DOS/Windows 3.1 you were forced to load all DOS device drivers at DOS boot-time via the CONFIG.SYS file. These drivers would then occupy all DOS sessions under Windows' 386 Enhanced Mode, impacting their available conventional memory and limiting the overall configurability of the Windows VDM architecture. Windows 95 suffers from this very same limitation. Any real-mode DOS device drivers that you wish to access from within Windows 95 must be loaded via CONFIG.SYS at boot-time. Thus, if you want access to a particular resource, and this resource requires a DOS device driver, you'll be forced to pay a penalty in terms of lost conventional memory and potential compatibility problems across all Windows 95 VDMs. And what about troublesome applications like games? Windows 95 features a special DOS session - the "Single MS-DOS Application Mode" - that allows such applications to execute unencumbered by the confines of a traditional Virtual DOS Machine (virtual I/O, video memory, etc.). What Microsoft doesn't publicize, however, is the fact that, in order to invoke this mode, you must essentially shut-down Windows 95. All running applications close, and the Windows 95 GUI itself is paged to disk. This entire process can take up to a minute depending on the speed of the hardware in use and the number of open applications - quite a disruption, especially when you're trying to finish that last minute memo or download a large file from a host system. OS/2 - RUNS DOS APPLICATIONS BETTER THAN DOS OS/2 really does eliminate the need for DOS. Its VDMs are completely configurable, allowing you to create individual CONFIG.SYS and AUTOEXEC.BAT files for each DOS session. This is an important option in those situations where a single device driver or TSR configuration for all VDMs would be inadequate. OS/2's VDMs are also highly backward-compatible and can also be configured to allow direct hardware access for applications that require it. And if an application truly refuses to run under OS/2 you can use the "dual-boot" option to run real DOS in about the same amount of time it takes you to invoke Windows 95's "Single MS-DOS Application Mode." INDEPENDENT SOFTWARE VENDOR COMMITMENTS ======================================= Windows 95: AN ISV HEADACHE One area where Microsoft continues to be uncertain is on the subject of API standards. Independent Software Vendors (ISVs) have been fighting an uphill battle in their efforts to pin-down Microsoft's overall API strategy. This is especially true of the native Windows 95 API, Win32c, which is itself a subset of the full Win32 API published nearly two years ago and implemented on Windows NT. Further exacerbating the situation is Microsoft's continual updating of the Win32c specification. New APIs emerge almost monthly, many of which extend Win32 in ways that tie applications to the Windows 95 platform. This has aggravated ISVs who wish to write cross-platform applications for Windows, Windows NT, and Windows 95. The only way these ISV's can write cross-platform applications, because of the different APIs support, is to poll the Kernel, determine which API is available and write dual or triple path code. With the APIs still in a state of flux there is no guarantee that the multiple path code will work. What this means to the 32-bit operating system customer is a potential delay in the release of Windows 95-compatible Win32 applications. Given the architectural limitations of Windows 95's Win16 application support - especially when multitasking and stability are major considerations - lack of Win32 applications could represent a serious obstacle to the platform's widespread adoption. Windows 95 needs Win32 applications before it even begins to make sense as a replacement for Windows 3.1. But given the confusion and frustration in the ISV community it may be some time before we see a substantial selection of Win32 titles. OS/2 - A CONSISTENT MESSAGE In contrast to Microsoft's "API du jour" strategy, IBM has stood firm on its promises to support open standards and honor ISV commitments. There is one 32-bit OS/2 Presentation Manager API for both client and server systems. Application functions written to that API will work across OS/2 versions running on Intel-based PC's, and will be easily portable to more advanced implementations in the future (including OS/2 for PowerPC). OS/2 currently boasts over 2000 native applications, all of which tap into the superior multitasking and performance. SUMMARY ======= OS/2: THE RIGHT ANSWER As you can see, so far Microsoft's Windows 95 operating system is long on hype and somewhat short on technology. But if you've followed their product offerings over the past few years, this revelation should really come as no surprise. Microsoft has a track record of delivering "cosmetically advanced" operating systems while ignoring the more important issues like robustness, capacity, and true object-orientation. In contrast, IBM has a very different track record, one that speaks of commitment to open standards and listening to customer needs. This is the same company that has been developing cutting edge OS technology for mainframe and minicomputer systems since the dawn of the information age. With OS/2, IBM has laid the foundation for a truly robust, high-capacity computing environment that preserves your existing investments while opening the door to the future. You can see the difference in areas like the OS/2 user interface. The WorkPlace Shell, in conjunction with the System Object Model (SOM), provide a truly object-oriented computing environment, one that thinks for you and doesn't break-down when you try to tap into its power. Likewise, OS/2's multitasking represents a no-compromises approach to bringing this powerful capability to the masses. From native OS/2 applications to its robust Win-OS2 VDMs, it is an operating system that can juggle your most complex tasks with ease. So in the end, the wise choice is obvious: OS/2 has the backward compatibility you want, the stability and reliability you need, and the kind of rock-solid commitment to excellence you've come to expect from the world's largest software company, IBM. Windows 95 looks more and more like a warmed-over version of yesterday's technology, not the "next generation Windows" platform that Microsoft is advertising it to be. So what about Windows 95? Good question! With one foot still buried in the DOS/Windows grave, Windows 95 is yesterday's technology dressed-up to look like tomorrow's 32-bit OS. Why wait for an impostor? OS/2 is here today, and represents the real future in personal computer operating systems. To GET WARPED, call 1-800-IBM-CALL, or see your local software dealer. APPENDIX A: FEATURES CHARTS FOR OS/2 AND Windows 95 ================================================ The following charts provide a summary of OS/2 and Windows 95 features, including multitasking characteristics, application environments, and bundled productivity tools. OS/2 WARP vs Windows 95 ON ARCHITECTURE FEATURE Warp Windows 95 32-bit Window Management Yes No (1) 32-bit Graphics Subsystem Yes No (2) 32-bit Printing Subsystem Yes Yes 32-bit Multimedia Subsystem Yes Yes 32-bit Kernel Yes Yes Demand Paged Virtual Memory Yes Yes HPFS Support Yes No Non-locking Input Queue (3) Yes No (Applications can keep running) (1) USER is 16-bit, non-reentrant code (2) 50% of GDI calls are serviced by 16-bit, non-reentrant code (3) WARP, new version of OS/2, has an engine that will unlock the input queue if it is locked OS/2 WARP vs Windows 95 ON APPLICATION ENVIRONMENTS FEATURE Warp Windows 95 16-bit OS/2 PM Applications Yes No 32-bit OS/2 PM Applications Yes No Win32s Applications (Ver 1.0 & 1.1) Yes Yes Preemptive Multitasking (4) Yes No Win16 Application Support Yes Yes Win16 Device Driver Support Yes Some (5) Number of 32-bit Applications 2000+ 0 (6) Available (4) See chart on multitasking comparison (5) Windows 3.x communications drivers need to be re-written (6) Native Windows 95 applications OS/2 WARP vs Windows 95 ON MULTITASKING CHARACTERISTICS FEATURE Warp Windows 95 Preemptive of 32-bit OS/2 and Yes No WIN32s version 1.1 applications Preemptive of DOS Applications Yes Yes Preemptive of Win16 Applications Yes No Preemptive of mixed 16/32-bit Yes No (8) Applications (7) Multiple, Protected Win16 VDMs Yes No (9) Crash Protection Yes No (10) Preemptive Multi-threading Yes Yes (7) 16 & 32 bit OS/2, WIN16, and WIN32s v1.1 applications (8) WinMUTEX prohibits access to USER and portions of GDI when a Win16 application is executing (9) All 16-bit applications share a single address space - the System Virtual Machine (VM) (10) Key operating system code structures (USER and GDI) share the System VM address space with 16-bit applications OS/2 WARP vs Windows 95 ON USER INTERFACE FEATURE Warp Windows 95 Folder Work Areas Yes No Integration with operating SOM Yes No (11) Launch Pad Yes Yes Drag & Drop Deletion Yes No Drag & Drop Faxing Yes Yes Drag & Drop Access Paths (change Yes No execution paths it will still work) Object Type Templates Yes No Parent Folder Closing Options Yes No (11) Windows 95 shell components are not OLE 2.01 objects" OS/2 WARP vs Windows 95 ON MULTIMEDIA FEATURE Warp Windows 95 Image Viewer Yes No Photo CD Support Yes No Autodesk Animation Yes No Play any Audio File from Internet Yes No Audio/Video Synch Manager Yes No MPEG Support Yes Yes 32-bit Audio/Video Playback Yes Yes OS/2 WARP vs Windows 95 ON BUNDLED APPLICATIONS FEATURE WARP Windows 95 Internet Access Tools Yes No FTP Yes No Telnet Yes No Gopher Yes No Newsreader Yes No WEB Explorer Yes No CompuServe Front-End Yes No Word Processor Yes No (12) Spreadsheet Yes No Database Yes No Charting Yes No Report Writer Yes No Electronic Mail Yes Yes Image Viewer Yes No FAX Yes Yes Phonebook Yes No Personal Information Mgr Yes No Sys Info Yes No VideoIn Yes No Video Conferencing Yes No (12) Windows 95 comes with a simple text editor, not a word processor REFERENCES ========== King, Adrian, "Windows (TM), the Next Generation: An Advanced Look at the Architecture of Chicago", Microsoft Systems Journal, January 1994, pp. 15-24. King, Adrian, "Memory Management, the Win32 (R) Subsystem, and Internal Synchronization in Chicago", Microsoft Systems Journal, May 1994, pp. 57-61. Pietrek, Matt, "Stepping Up to 32 Bits: Chicago's Process, Thread, and Memory Management", Microsoft Systems Journal, August 1994, pp. 27-41. Pietrek, Matt. "Investigating the Hybrid Windowing and Messaging Architecture of Chicago". Microsoft Systems Journal. September 1994. pp. 15-30. Pietrek, Matt, "Which Win32 Is For You?", PC Magazine, September 1994. NOTICE ====== The information contained in this document represents the current view of IBM Corporation on the issues discussed at the date of publication. Because IBM must respond to changing market conditions, it should not be interpreted to be a commitment on the part of IBM. All information, claims, references, and comparisons relating to Windows 95 in this document are based upon non-confidential information currently available as of the date of publication. This document is for informational purposes only. IBM makes NO WARRANTIES, EXPRESSED OR IMPLIED, IN THIS SUMMARY. 1994 IBM Corporation. All Rights Reserved. Printed in the United States of America. OS/2 is a registered trademark of International Business Machines Corporation. Microsoft is a registered trademark and Windows is a trademark of Microsoft, Inc. NetWare is a registered trademark of Novell, Inc.